Columbia Kermit/kermit.zip/newsgroups/misc.20010306-20010921/000194_Use-Author-Add…-Header@[127.1]_Sat Jun 2 13:06:21 EDT 2001.msg

Text File | 2020-01-01 | 7KB | 181 lines

Article: 12502 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!news.verio.net!nntp.frontiernet.net!nntp-new.frontiernet.net!nntp.gblx.net!border1.nntp.aus1.giganews.com!nntp2.aus1.giganews.com!newshub2.rdc1.sfba.home.com!news.home.com!cyclone-sjo1.usenetserver.com!news-out-sjo.usenetserver.com!hub1.nntpserver.com!news-in.nibble.net!newsfeed01.sul.t-online.de!t-online.de!newsrouter.chello.at!newsfeed.Austria.EU.net!newsfeed.kpnqwest.at!anon.lcs.mit.edu!nym.alias.net!mail2news
Date: 2 Jun 2001 01:43:25 -0700
Message-ID: <[e-mail]>
X-Sent: 2 Jun 2001 08:43:25 GMT
Content-Type: text/plain
Content-Disposition: inline
Mime-Version: 1.0
From:  <Use-Author-Address-Header@[127.1]>
Author-Address: leganii <AT> surfree <DOT> com
Cc: [e-mail], [e-mail], [e-mail],
  [e-mail]
X-Mailer: Web Mail 3.9.2.3
Subject: Smashing through Screen with Kermit
X-Sent-From: [e-mail]
Mail-To-News-Contact: [e-mail]
Organization: [e-mail]
Newsgroups: comp.protocols.kermit.misc
Lines: 159
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:12502


As an intermediate step to getting them ethernetted,
I finally got my OS/2 and Debian boxes connected over
a Null-modem cable.  I figure that being able to twiddle
configuration settings and reboot them sitting at one
console has to simplify the process for one who
has a lot to learn about networking.
Until I have Ethernet going the serial connection provides
a working 'out-of-band' connection.
How hard can it be to network the computers if they are
already networked?
This is more functional than a lot might think
having 'screen', a full screen 'window manager'
running on the Debian box, enabling multiple sessions
with one login, split screens, scrollback, cut and paste,
etc. from a text interface.
There are only two disadvantage to this that I know so far.

1) You can't take advantage of recent releases of Lynx, W3M,
and other text mode browsers to view images with viewers
like zgv.

2) The very first thing brought up in the screen FAQ is
'Why can't I transfer files with Kermit while screen is running?'.
The answer given, that you can't, is true only for the case
where you give up without analyzing the problem and
determining how Kermit transfer has to be configured to work.
Yes, over a simple serial connection you are restricted
to leaving other screen managed sessions to themselves
while the transfer goes on, but for me that is more convienient
than having to shutdown screen.
(I find it so usefull I 'exec screen -R' at the end my
bash_profile file so that it is always running when I login.)


First add this line to /etc/inittab on the Debian machine
to allow loggin in on port 'com2'/ttyS1:

T1:23:respawn:/sbin/getty -L ttyS1 57600 vt100

(You might also want to experiment with Lilo and/or GRUB,
which allow control of boot-up over serial connections,
but that might be for another write up.)

The following script, run with Kermit/2 from the OS/2
end sets up C-Kermit on the Debian machine into server mode
and sets both so that file transfers happen.
The two external modem connection cables I'm using, spliced
together with gender menders and null modem adaptors is
kind of long (the PCs are in different rooms), and
runs past some wire nests, and I'm not certain about shielding,
so I found setting the allowed errors higher than the default
seemed needed.  For a 36K file about 16 errors happened during
transfer, so my setting is excessive, but does the trick.
Without the settings of this script the transfer seemed to
lockup, as the screen FAQ indicated.
(If anyone knows any improvements, feel free to contact me.)

#     Screen Smasher
#    ( To 'Smash through Screen with file transfers' )
#
#    for setting up kermit server
#    at the other end to penetrate a
#    connection where the UNIX session manager
#    'screen' is also running at the other end,
#    without having to shutdown 'screen'.
#
#    D.E. Legan 26/05/2001


#  set this, last character of the remote prompt,
#  in one place, so it can easily be changed for
#  different circumstances:
define rprompt {>}

#    first do as I *do*, not just as I *say*,
#    set these things locally on OS/2 Kermit/2:
set prefixing all
set send timeout 1 fixed
set receive timeout 1
set send start-of-packet 65
set receive start-of-packet 65
set transfer locking-shift on
set retry  500
#     ....  nothing succeeds like excess!

:bangaway

#   First, make an attempt to make sure kermit is actually running
#   on the other end.  This seems to do no harm if  it already is.
#   Although I actually have never used it for such, the help
#   for C-Kermit indicates that the 'kermit' command issued
#   at the kermit prompt serves to set command line switches
#   after it has already been started.  Here, if the other end
#   is still at the shell prompt, it starts kermit.
#   If kermit is already running, as already mentioned, it does no harm.
output  kermit\13
input 5 \m(rprompt)
if failure goto bangaway

#  This next command causes all non-visable, or non-standard
#  bytes to be prefixed to be a standard ASCII character.
#  While differing in specific details, in essence it can
#  be likened to uuencoding or MIME base-64 encoding on
#  the fly, allowing only standard, visable ASCII characters
#  and carriage returns over the connection.
#  Surely these will not interfere with 'screen''s operation!  :-)
output  set prefixing all\13
input 5 \m(rprompt)
if failure goto bangaway

output  set send timeout 1 fixed\13
input 5 \m(rprompt)
if failure goto bangaway

output  set receive timeout 1\13
input 5 \m(rprompt)
if failure goto bangaway

#   Now set the start of packet character to simply the letter 'A':
output  set send start-of-packet 65\13
input 5 \m(rprompt)
if failure goto bangaway

output  set receive start-of-packet 65\13
input 5 \m(rprompt)
if failure goto bangaway

# According to 'Using C-Kermit', the following is almost never bad,
# so....
output  set transfer locking-shift on\13
input 5 \m(rprompt)
if failure goto bangaway

output  set retry  500\13
input 5 \m(rprompt)
if failure goto bangaway

#  When developing this script, overlooked that this next one would
#  have a different response than just the remote prompt,
#  and thought that some how the local OS/2 machine was
#  being put into server mode when 'kermit ready to serve...'
#  was echoed on the local screen and then it locked up in an
#  infinit loop.
output  server\13
input 5 kermit ready to serve...
if failure goto bangaway


#  now see what you can do:
remote help




Regards,
Dallas E. Legan II  /  [e-mail]  /  [e-mail]

Powered by......Lynx, the Internet at hyperkinetic speed.